[PATCH 11/36] cmd/libsnap-confine-private: Defend against hardlink attacks
authorAlex Murray <alex.murray@canonical.com>
Wed, 17 Nov 2021 03:57:22 +0000 (14:27 +1030)
committerMarkus Koschany <apo@debian.org>
Tue, 13 Jun 2023 09:28:53 +0000 (10:28 +0100)
commit2333a89e9be6e042a019411522d59e72d626abd1
treeba764d106d754a0971c77c9cfcd8cc4381083f5b
parent6d24d7f694f824944d14c4fb5c414df0e804e0eb
[PATCH 11/36] cmd/libsnap-confine-private: Defend against hardlink attacks

When snap-confine goes to execute other helper binaries (snap-update-ns
etc) via sc_open_snapd_tool(), these other binaries are located relative to
the currently executing snap-confine process via /proc/self/exe. Since it
is possible for regular users to hardlink setuid binaries when
fs.protected_hardlinks is 0, it is possible to hardlink snap-confine to
another location and then place an attacker controlled binary in place of
snap-update-ns and have this executed as root by snap-confine. Protect
against this by checking that snap-confine is located either within
/usr/lib/snapd or within the core or snapd snaps as expected.

This resolves CVE-2021-44730.

Signed-off-by: Alex Murray <alex.murray@canonical.com>
Gbp-Pq: Topic cve202144730
Gbp-Pq: Name 0011-cmd-libsnap-confine-private-Defend-against-hardlink-.patch
cmd/libsnap-confine-private/tool.c
cmd/libsnap-confine-private/utils-test.c
cmd/libsnap-confine-private/utils.c
cmd/libsnap-confine-private/utils.h